<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'No telephone required',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2019/03/26.jpg" alt="A mountain visible from the city" class="framed-centred-image" width="649" height="480"/>
<section id="money">
	<h2>Lost money</h2>
	<p>
		As expected, the customer service representative at the grocery store had no idea what they were talking about.
		I stopped into the bottle-redemption centre, and they looked up the transaction and credited the lost money to my account.
		There was no hassle, and absolutely <strong>*no*</strong> reason to call them via telephone.
	</p>
	<p>
		I can see why calling by telephone if the incident had occurred during their business hours might be convenient.
		It could have been fixed right after it happened, and I could have gotten my groceries instead of biking home empty-handed.
		Even better, the customer service representative said they&apos;d call on my behalf, so I wouldn&apos;t even need to <strong>*touch*</strong> a telephone.
		However, once I leave the store, all convenience of getting it fixed via telephone completely goes out the window.
		I could drop by the grocery store if I really had to, but it&apos;s easier to just drop by the redemption centre as I had to go there to drop off more bottles anyway.
	</p>
</section>
<section id="Perl">
	<h2>Perl</h2>
	<p>
		I&apos;ve decided that the lack of encapsulation in Perl isn&apos;t a deal-breaker.
		I&apos;ll just have to drastically change how certain classes behave, such as my $a[URI]-related classes.
		Instead of operating on objects, they&apos;ll need to operate on $a[URI] strings themselves.
		It&apos;ll be a bit less efficient, but it should be fine.
	</p>
	<p>
		Another thought occurred to me though, which was the fact that variables are namespaced in Perl.
		This is a very good thing.
		Don&apos;t get me wrong.
		But it requires me to re-evaluate where I draw the line between library code and main program code.
		In $a[PHP], I draw the line at the namespace, so anything that can be and is namespaced belongs in a library while anything that cannot be and is not is instead included in the main program.
		All variables therefore belong in the main program, which logically makes sense with the way $a[PHP] works.
		Using this same policy in Perl would put every last variable, if I understand correctly, into the library, which I think makes significantly less sense.
		It might actually make more sense than I gave it credit for at first though, so I need to think on it and try to figure out exactly how I&apos;d set that up.
		Basically, I might have set up a system much like what I&apos;d have with Perl&apos;s namespaced variables, but in $a[PHP].
		If the goal had been namespaced variables, I would have used static class variables or something, but the goal was for me to not mangle my own variables, so I moved as many variables as I could feasibly manage to all into the same file.
		I hadn&apos;t finished the clean-up to get the last of the variables into the file, but I&apos;d have two legs up in Perl.
		The first would be that this time, I&apos;m starting from scratch.
		I&apos;d be starting over with the goal in mind.
		Previously, cleaning up the variable definitions was an afterthought.
		Secondly, Perl would <strong>*make me*</strong> do it.
		In $a[PHP], it doesn&apos;t matter where variables are defined because they&apos;re all dumped into one pot, but in Perl, getting them into correct namespace right away would need to be done from the start.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion posts for the day:
	</p>
	<blockquote>
		<p>
			I like your nested clusters diagram.
			It shows another way of looking at the data presented in a dendrogram.
		</p>
		<p>
			You make a good point about hierarchical clustering being a form of unsupervised learning.
			We don&apos;t have the right answer, and are instead asking the computer to find said right answer without any prior information about the problem.
			Unsupervised learning tends to be a rather limited too, mainly only able to perform classifications.
			Classification is exactly what we need when engaging in hierarchical clustering though.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I hadn&apos;t thought about the need to reduce dimensionality before attempting to use hierarchical clustering.
			It certainly makes sense to do that though.
			With too many variables, it can be harder to understand the computed results.
			Even worse, variables of lesser importance may be used over ones of grater importance at times.
			Removing less-important dimensions can alleviate both problems.
		</p>
		<p>
			I also hadn&apos;t even considered the possibility of seeking a balanced dendrogram.
			I guess that could be useful in some cases, but like you said, other cases such as medical studies would suffer from doctoring the dendrogram in such a way, and are better off with the more-natural dendrograms, which tend to be unbalanced.
		</p>
		<p>
			Thanks for the good read!
			I learned a lot.
		</p>
	</blockquote>
	<blockquote>
		<p>
			In the short term, yes, going back and fixing your legacy code will lead to costs and potentially some risks.
			In the long term, it&apos;ll save lots of money (new maintainers won&apos;t ave to spend as much time trying to learn the legacy code&apos;s quirks and all maintainers won&apos;t have to try to work around the quirks) and lead to better, more-secure code.
			If code relies on white box knowledge, you&apos;ve got one of several situations. 0) The dependence on the white-box-dependant code is a legacy feature, in which case it needs to be fixed. 1) The white-box-dependency is fine, but the implementation of the white box was legacy code, meaning that anything dependant on that implementation is legacy code and thus needs to be fixed. In that case, the code needs to be updated to use the modern feature set. 2) The update to the white box doesn&apos;t interfere with the code that depends on it, so there&apos;s nothing that needs to be updated in the dependant code in that regard.
		</p>
		<p>
			I have a low tolerance for badly-written code.
			I&apos;ve seen way too many lazy developers write code that&apos;s terrible even at the time they wrote it, let alone after the code has aged.
			It gives me a really low tolerance for badly-written code, including legacy code that was fine at the time it was written..
		</p>
		<p>
			$a[HTTP] compression is negotiated by the server and the client.
			I don&apos;t understand your question about <code>&lt;script/&gt;</code> tags not doing it by default.
			It&apos;s not the markup that&apos;s the problem, it&apos;s the server configuration.
			If you&apos;re on, say, Apache, you can configure Apache to try to compress all outgoing files.
			If the Web browser indicates in its request that it can handle such compression, whatever file it requested will be compressed before being sent over the wire.
			This would include any JavaScript files, webpages, and even image files sent to the browser.
			The browser then decompresses before attempting to render.
			It basically trades some transmission time for some extra processor time.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I agree that two-factor authentication via telephone is insecure, though it&apos;s not just number-swapping that&apos;s an issue.
			It&apos;s way too easy to eavesdrop.
			The government, at least in my country, pretty much eavesdrops on all the telephone stuff, so it seems plausible that other attackers are doing the same on a lesser scale.
			Like you said, emails don&apos;t tend to be encrypted though.
			Two-factor authentication via $a[PGP]-encrypted email would be awesome, but I haven&apos;t seen it actually implemented yet.
			At this point, I&apos;d just be happy to have everyone stop pushing the everyone-has-to-have-a-telephone-and-give-our-company-the-number mentality.
			Not everyone has a telephone line.
			I know I don&apos;t.
			And not everyone that has a telephone wants companies pestering them via telephone, be that for two-factor authentication of for anything else.
		</p>
		<p>
			I agree that the one-time password applications are a much better solution.
			The problem is I haven&apos;t seen any that aren&apos;t exclusive to mobiles yet.
			If I could get a free software one that runs on Debian, I&apos;d be thrilled to use it.
			And like you said, two-factor authentication isn&apos;t exactly a feature that can be used during registration.
		</p>
	</blockquote>
</section>
END
);
